System and method for network layer protocol routing in a peer model integrated optical network

ABSTRACT

Embodiments of the invention are generally directed to a system and method of implementing peer model architecture in integrated optical networks. In one embodiment, heterogeneous domains of nodes share a common control plane via routing and signaling adjacencies established through a network layer control channel. For example, in one embodiment, one or more Internet Protocol (IP) compliant routers, one or more Time Domain Multiplexing (TDM) switches, and one or more Wave Division Multiplexing (WDM) optical cross connects (OXC) run a common instance of an Interior Gateway Protocol (IGP).

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/392,621 entitled “SYSTEM AND METHOD FOR NETWORK LAYER PROTOCOLROUTING IN A PEER MODEL INTEGRATED OPTICAL NETWORK,” filed on Mar. 19,2003, which claims the benefit of priority under 35 U.S.C. § 119(e) ofU.S. Patent Application No. 60/412,385, entitled, “SYSTEM AND METHOD OFIMPLEMENTING PEER MODEL IN INTEGRATED OPTICAL NETWORKS,” filed on Sep.20, 2002.

This nonprovisional patent application is related to contemporaneouslyfiled nonprovisional patent application number <004998.P016>entitled “ASystem and Method for Implementing A Peer Model Architecture inIntegrated Optical Networks,” contemporaneously filed nonprovisionalpatent application number <004998.P018> entitled “A System and Methodfor Routing Information in a Peer Model Integrated Optical Network,” andcontemporaneously filed nonprovisional patent application number<004998.P020> entitled “System and Method for Switching in a Peer ModelIntegrated Optical Network.”

TECHNICAL FIELD

Embodiments of the invention generally relate to the field of integratedoptical networks and, more particularly, to a system and method forimplementing peer model architecture in integrated optical networks.

BACKGROUND

FIG. 1 is a block diagram illustrating selected elements of conventionalnetwork 100. Conventional network 100 includes one or more InternetProtocol (IP) routers (e.g., IP router 110) surrounding a domain 120 ofcircuit providing elements (e.g., switch 130). The IP routers andcircuit providing elements are connected together by a number of links(e.g., link 140 and 150). A link is a physical or logical connectionbetween two points capable of transporting digitally encoded voice anddata traffic.

The circuit providing elements within domain 120 may be AsynchronousTransfer Mode (ATM) switches, Time Domain Multiplexing (TDM) switches,Wavelength Division Multiplexing (WDM) optical cross-connects (OXCs), orthe like. The term “switch” may refer to an ATM switch, a WDMcross-connect, a TDM switch or similar circuit providing element.Typically, domain 120 comprises an optical layer of conventional network100 and the one or more IP routers (e.g., IP router 110) comprise anelectrical layer of conventional network 100. The optical layer'sprimary function may be to provide circuit services to the one or moreIP routers. Circuit services refer to services provided to nodes toestablish temporary connections between the nodes.

FIG. 2 is a block diagram illustrating the logical decomposition of IProuter 210 and TDM switch 220. IP router 210 and TDM switch 220 may belogically decomposed into a control plane, a management plane, and aforwarding plane. The logical decomposition of IP router 210 and TDMswitch 220 into these three planes provides a means for networkengineers to more easily design networks comprising nodes of differentswitching technologies.

The term control plane refers to the entities involved in the functionsof signaling and routing within a network. Signaling is the process ofexchanging control messages between network nodes and is typically usedfor dynamic connection set-up across a network. Routing refers toadjacency discovery, propagation of reachability information, pathcalculation, path selection process and the like. Control plane entitiesmay include control plane processors 241 and 243, various softwareprocesses, and the like.

The term management plane refers to the entities involved in thefunctions of configuring and managing a node (e.g., IP router 210 andTDM switch 220). The management functions may relate to management ofdevices, of the networking layer, of services, or the like. Managementplane entities may include management processors 251 and 253. A personof ordinary skill in the art will recognize that a single processor maybe used to perform both control plane functions and management planefunctions.

The term forwarding plane refers to the entities involved in themanipulation and forwarding of digitally encoded voice and data.Examples of forwarding plane entities include line cards (e.g., linecards 255 and 257), Forwarding Information Bases (not shown), and thelike.

Referring again to FIG. 1, the IP routers and the circuit providingelements form two distinct domains (e.g., an IP domain and a transportdomain). The routing, topology distribution, and signaling protocols inthe IP domain are independent of the routing, topology distribution, andsignaling protocols in the transport domain. Since the IP domain and thetransport domain run separate instances of routing and signalingprotocol processes, the control plane of the IP domain is independent ofthe control plane of the transport domain.

In the past few years, there has been significant interest within theindustry to move towards a unified set of mechanisms that will enableservice providers to manage separate network elements in a uniform way.Such a unified set of mechanisms is central to managing a networkcomposed of a wide range of elements, from IP routers, to SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) crossconnects, to optical cross-connects. The traditional transport network,for example, has so far not had such a common framework. Indeed, theSONET network infrastructure does not have any control plane at all (ithas only a management infrastructure) because the need for automaticprovisioning was not envisioned when SONET/SDH networks were initiallydeveloped. As the extent of SONET networks grew, however, the manualprovisioning process became increasingly slow and often error prone,motivating the need for a better solution. In parallel, the InternetProtocol (IP) and its associated protocols have matured to become theubiquitous routing and signaling mechanisms for transporting packetdata. Further, this packet infrastructure also has evolved to introducethe idea of decoupling routing from packet forwarding (viamulti-protocol label switching, for example), thus allowing for virtualcircuit setup and traffic engineering in packet networks.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example, and notby way of limitation, in the figures of the accompanying drawings inwhich like reference numerals refer to similar elements.

FIG. 1 is a block diagram illustrating selected elements of conventionalnetwork 100.

FIG. 2 is a block diagram illustrating the logical decomposition of anIP router 210 and a TDM switch 220.

FIG. 3 is a block diagram illustrating selected elements of network 300implementing certain aspects of the invention.

FIG. 4 is an illustration of the P domain topology of network 300.

FIG. 5 is an illustration of the IPCC topology of network 300.

FIG. 6 is an illustration of the IP topology of network 300.

FIG. 7 is a block diagram illustrating selected elements of P node 700.

FIG. 8 is an illustration of packet classification and processing withina P node.

FIG. 9 is block diagram illustrating selected elements of T node 900.

FIG. 10 is an illustration of packet classification and processingwithin a T node.

FIG. 11 is a block diagram illustrating selected portions of LSA 1100

FIG. 12 is a flow diagram illustrating certain aspects of a method forgenerating a routing advertisement message, according to an embodimentof the invention.

FIG. 13 is a flow diagram illustrating certain aspects of a method forprocessing routing advertisement messages, according to an embodiment ofthe invention.

FIG. 14 is a flow diagram illustrating certain aspects of method 1400for processing Link State Advertisement messages in an Internet Protocolcompliant router, according to an embodiment of the invention.

FIG. 15 is a flow diagram illustrating certain aspects of method 1500for processing a packet in an Internet Protocol compliant router,according to an embodiment of the invention.

FIG. 16 is a flow diagram illustrating certain aspects of method 1600for processing Link State Advertisement messages in a Time DivisionMultiplexing switch, according to an embodiment of the invention.

FIG. 17 is a flow diagram illustrating certain aspects of method 1700for processing a packet in a Time Division Multiplexing switch,according to an embodiment of the invention.

DETAILED DESCRIPTION

Embodiments of the invention are generally directed to a system andmethod of implementing peer model architecture in integrated opticalnetworks. In one embodiment, heterogeneous domains of nodes share acommon control plane via routing and signaling adjacencies establishedthrough a network layer control channel. For example, in one embodiment,one or more Internet Protocol (IP) compliant routers, one or more TimeDomain Multiplexing (TDM) switches, and one or more Wave DivisionMultiplexing (WDM) optical cross connects (OXC) run a common instance ofan Interior Gateway Protocol (IGP). Table 1 provides a number ofdefinitions and descriptions to facilitate disclosure of embodiments ofthe invention.

TABLE 1 Term Definition/Description P (or packet) node A P node may bean IP router or the hardware and software within a hybrid system thatrealizes IP router functionality. A P node may be either a physical orlogical system that functions as an IP router. T (or TDM) node A T nodemay be a TDM switch or the hardware and software within a hybrid systemthat realizes TDM switch functionality. A T node may be either aphysical or logical system that functions as a TDM switch. W node A Wnode is a WDM optical cross connect or the hardware and software withina hybrid system that realizes WDM optical cross connect functionality. AW node may be either a physical or logical system that functions as aWDM optical cross connect. P (or packet) link A P link may be a physicalor logical link that connects two P nodes. T (or TDM) link A T link maybe a physical link that connects two T nodes. Also, A T link may be aphysical link that connects a T node with a P node. W (or WDM) link A Wlink may be a physical link that connects two W nodes. Also, A W linkmay be a physical link that connects a W node with a P node. IP controlchannel An IPCC link may be an in-band or out-of- (IPCC) link band datacommunication channel that connects each pair of devices that have a TDMlink or WDM link between them. The IPCC link may be used to transmit IProuting and signaling messages. In one embodiment of the invention, anIPCC link is used to connect a TDM switch with one of an IP router and aTDM switch. P domain A P domain is one or more P nodes that run a singleinstance of the IP routing and signaling protocols. T domain A T domainis one or more T nodes that run a single instance of the IP routing andsignaling protocols. W domain A W domain is one or more W nodes that runa single instance of the IP routing and signaling protocols.

Embodiments of the invention described herein use IP based signaling androuting protocols to dynamically control and manage end-to-end data flowin heterogeneous multi-layer networks, which include IP, TDM, and WDMbased equipment. For the IP routing and signaling messages to flowbetween these network nodes, either an in-band or an out-of-band IPcontrol channel may link every pair of nodes connected by a data bearinglink. Thus, to dynamically control end-to-end data flow, it is desirablefor a network to have a unified IP based control plane and a layeredforwarding plane comprised of a mixture of IP, TDM, and WDM forwardingplanes.

Peer Model Architecture

In a network having a unified IP based control plane, an IP router maybe a peer of a TDM switch (or a WDM OXC). Therefore, such networkingarchitecture may be called “peer model architecture.” In peer modelarchitecture, IP routers and TDM switches may be connected to each otherin the control plane via routing and signaling adjacencies over an IPcontrol channel (IPCC). According to the peer model, a single instanceof the IP based signaling and routing stacks (with optics-basedextensions) may be run on both IP routers and TDM switches (or WDMOXCs). Since a single instance of signal and routing stacks is utilized,routers may compute and signal end-to-end paths across an opticaltransport domain.

To distribute topology information through a network implementedaccording to peer architecture, a common instance of an Interior GatewayProtocol (IGP) may be used throughout an integrated network. An IGP is aprotocol that defines how routers (and also TDM switches and OXC) withinan autonomous system communicate with each other. Three example IGPs arethe Routing Information Protocol (RIP), the Open Shortest Path FirstProtocol (OSPF), and the Intermediate System to Intermediate System(IS-IS) protocol.

Since nodes within a peer type network run a common instance of an IGP,it may be desirable for those nodes to share a common address space. Theterm common address space refers to all nodes within the peer typenetwork having a unique address. In one embodiment of the invention, allnodes within a peer type network have unique IP addresses. According tosuch an embodiment, an IP address may belong to either a TDM switch oran IP router but it cannot belong to both devices.

FIG. 3 is a block diagram illustrating one embodiment of selectedelements of network 300, implemented according to an embodiment of theinvention. Network 300 may include one or more P nodes (e.g., P node310) and one or more T nodes (e.g., T node 320), connected together byone or more physical (and/or logical) links (e.g., P-link 330). A P nodemay be an IP router or the hardware and software within a hybrid systemthat realizes IP router functionality. A T node may be a TDM switch orthe hardware and software within a hybrid system that realizes TDMswitch functionality.

Network 300 comprises P domain 340 and T domain 350. The term domain, asused herein, refers to one or more nodes running a common instance of arouting protocol (and/or a signaling protocol). A P domain (e.g., Pdomain 340) refers to a domain of P nodes. Similarly, a T domain (e.g.,T domain 350) refers to a domain of T nodes. Alternative embodiments ofthe invention may comprise a P domain and a W domain. Also, somealternative embodiments of the invention may comprise three or moredomains (e.g., a P domain, a T domain, and a W domain).

As shown in FIG. 3, the forwarding planes of P nodes in a peer typenetwork may be fully connected, making the packet network topology anoverly of the physical transport network. Thus, “peering” between IPdevices and TDM/optical devices is typically in the control andmanagement planes. The unification of the control and management planesincreases the interaction between the IP and TDM/optical domains byallowing for a single management interface that can control both the IPand TDM/optical domains.

FIG. 4 is a block diagram illustrating the P domain topology of network300. The P domain may include one or more P nodes (e.g., P nodes 430 and440) and one or more P links (e.g., P links 410 and 450). A P link maybe a physical link (e.g., P link 410) or a logical link (e.g., P link450). P links may carry data, control, and management packets. As willbe further discussed below, the P domain topology may be used togenerate a P link-Forwarding Information Base (P-FIB).

FIG. 5 is a block diagram illustrating the Internet Protocol ControlChannel (IPCC) topology of network 300. An IPCC may be an in-band orout-of-band data communication channel that connects each pair ofdevices that share a T link. For example, IPCC 510 connects P node 520and T node 530. Similarly, IPCC 540 connects T node 550 with T node 560.As will be further described below, the IPCC topology may be used togenerate an IPCC link-Forwarding Information Base (T-FIB).

FIG. 6 is a block diagram illustrating the IP topology of network 300.In peer type networks, the IP topology may include all of the nodeswithin the peer network and the P links and IPCC links connecting thosenodes. For the embodiment illustrated in FIG. 3, the IP topology may bebased on the union of the P domain topology (shown in FIG. 4) with theIPCC topology (shown in FIG. 6). Thus, the IP topology of network 300includes physical P links (e.g., P links 610 and 620), logical P links(e.g., P link 630), and IPCC links (e.g., IPCC 640). As will be furtherdiscussed below, the IP topology may be used to generate aglobal-Forwarding Information Base (G-FIB).

Forwarding is the process of passing a packet or message on to anintermediate or final destination. Forwarding may involve a number ofprocesses including IGPs, Link State Databases (LSDBs), ForwardingInformation Bases (FIBs), and Constrained Shortest Path First (CSPF)algorithms. While forwarding will be described in connection with linkstate protocols (e.g., OSPF), a person of ordinary skill in the art willappreciate that embodiments of the invention may be implemented usingother types of routing protocols including distance-vector protocols.

Network nodes employing link state protocols (e.g., OSPF or IS-IS)typically maintain a partial map of the network in which they reside.When a network link changes state (e.g., up to down, or vice versa), anotification, called a Link State Advertisement (LSA) message may beflooded throughout the network. An LSA message may be a wide variety ofmessages implemented according to a routing protocol to conveyinformation about the state of one or more links.

A Link State Database (LSDB) is a data structure maintained in a node(e.g., P node 310 and T node 320 shown in FIG. 3) based on informationobtained from received LSA messages. Forwarding Information Bases (FIBs)may be derived from the LSDBs. The derivation of FIBs from LSDBs is wellknown in the art and will not be further discussed except as to how itpertains to embodiments of the invention.

The forwarding of packets at a node is based on the FIB. Conventionalnodes use the destination address of the packet to extract from the FIBthe identity of the outgoing interface to which the packet should beforwarded. Conventional nodes may also direct certain packets (e.g.,control and management packets) to one more control processors withinthe node. Processors in the forwarding plane of the receiving node mayidentify the control and management packets. The control processor(s)may hand the packet to the appropriate software process (e.g., an OSPFor Resource Reservation Protocol process) responsible for processingthat specific type of packet.

Within an IP router, the FIB may be located on one or more line cards sodata packets typically only travel through the packet forwarding plane.Control and management packets, however, are directed from the line cardto the control/management processor(s). In a TDM switch, on the otherhand, the only IP packets typically arriving are control/managementpackets, and these are directed from the line card to thecontrol/management processor(s) for further processing.

Referring again to FIG. 3, since a single IGP instance runs in multipledomains (e.g., P domain 340 and T domain 350), nodes within network 300may selectively forward packets to different domains. As will be morefully described below in connection with FIGS. 8 and 10, packetforwarding may depend, in part, on the domain in which a destinationnode resides and the type of packet that is to be forwarded. In someembodiments of the invention, particular types of packets are to berouted over particular types of links. Therefore, nodes in network 300may have to consider multiple network topologies (e.g., P domaintopology 400, IPCC topology 500, and IP topology 600), during packetforwarding.

In some embodiments of the invention, each node maintains a mapping(e.g., a data structure with entries providing a mapping) of IPaddress-to-domain in which the node with that IP address resides (IPaddress-to-domain mapping). In some embodiments of the invention, thismapping is accomplished through domain information that is carried inLink State Advertisement messages that are flooded throughout a network.In alternative embodiments of the invention, the mapping is manuallyconfigured at each node within the network. As will be further describedbelow with respect to FIGS. 8 and 10, the IP address-to-domain mappingmay be used by P nodes and T nodes when forwarding packets.

In some embodiments of the invention, incoming packets may be one offour packet types: IP data packets, control packets (e.g., routing andsignaling packets), management packets, and ping packets. Also, in someembodiments of the invention, incoming packets may be viewed asbelonging to one of eight traffic classes: IP data traffic, routingtraffic, P- or T-domain destined signaling traffic, P- or T-domaindestined management traffic, and P- or T-domain destined ping packets.The traffic class of a packet may be a function of its packet type andthe domain in which the destination node resides. The use of trafficclasses in packet forwarding will be further described below inconnection with FIGS. 8 and 10.

P Node Architecture and Processes

FIG. 7 is a block diagram illustrating selected elements of P node 700.P node 700 may include: one or more control processors 710, one or moremanagement processors 720, memory 730, one or more Input/Outputinterfaces 740, line cards 750-753, and switch fabric 760. Theillustrated elements may be connected together through systeminterconnect 770. One or more control processors 710 and one or moremanagement processors 720 may include a microprocessor, microcontroller,field programmable gate array (FPGA), application specific integratedcircuit (ASIC), central processing unit (CPU), programmable logic device(PLD), and similar devices that access instructions from system storage(e.g., memory 730), decode them, and execute those instructions byperforming arithmetic and logical operations. In some embodiments of theinvention, one or more control processors 710 and one or more managementprocessors 720 are implemented with a common processor or processors.

Memory 730 may encompass a wide variety of memory devices includingread-only memory (ROM), erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), randomaccess memory (RAM), non-volatile random access memory (NVRAM), cachememory, flash memory, and other memory devices. Memory 730 may alsoinclude one or more hard disks, floppy disks, ZIP disks, compact disks(e.g., CD-ROM), digital versatile/video disks (DVD), magnetic randomaccess memory (MRAM) devices, and other system-readable media that storeinstructions and/or data. Memory 730 may store program modules such asroutines, programs, objects, images, data structures, program data, andother program components that perform particular tasks or implementparticular abstract data types that facilitate system use.

Line cards 750-753 provide an interface between communication channels780-783 and other elements of P node 700. Line cards 750-753 represent abroad range of interface elements capable of providing transmittingand/or receiving ports connecting P node 700 to communication channels780-783. A person of ordinary skill in the art will appreciate that thenumber of line cards in P node 700 may be fewer or greater than thenumber shown in FIG. 7.

Switch fabric 760 provides the interconnect architecture used to switchpackets from incoming communication channels (e.g., 780 and 782) withoutgoing communication channels (e.g., 781 and 783). Switch fabric 760represents a wide array of interconnect architectures capable of packetswitching. Switch fabrics are well known in the art and, therefore, willnot be further described except as to embodiments of the invention.

One or more I/O interfaces 740 may include a hard disk drive interface,a magnetic disk drive interface, an optical drive interface, a parallelport, serial controller or super I/O controller, serial port, universalserial bus (USB) port, a display device interface (e.g., video adapter),a network interface card (NIC), a sound card, modem, and the like.System interconnect 770 permits communication between the variouselements of P node 700. System interconnect 770 may include a widevariety of signal lines including one or more of a memory bus,peripheral bus, local bus, host bus, bridge, optical, electrical,acoustical, and other propagated signal lines.

P node 700 may receive one or more Link State Advertisement (LSA)messages (e.g., via communication channels 780 and 782) containinginformation about one or more links that are in the same network as Pnode 700. In embodiments of the invention employing a link-state routingprotocol, P node 700 may maintain one or more Link State Databases(LSDBs) containing information from the one or more received LSAmessages.

P node 700 maintains two or more FIBs (derived from the one or moreLSDBs) depending on whether P node 700 is an interior P node or anexterior P node. An interior P node is a P node that is not connected bya link to a node from another domain (e.g., P node 310 shown in FIG. 3).An exterior P node is a P node that is connected by one or more links toa node from a different domain (e.g., P node 360 shown in FIG. 3).

In some embodiments of the invention, P node 700 maintains separateLSDBs for LSA messages pertaining to P links and LSA messages pertainingto IPCC links. In such embodiments, P node 700 may derive separate FIBsfor each LSDB it maintains. In alternative embodiments of the invention,P node 700 maintains a global LSDB and generates separate FIBs byrunning a CSPF algorithm on subsets of a global LSDB.

In either case, P node 700 may generate three different FIBs: a Plink-FIB (P-FIB), an IPCC link-FIB (T-FIB), and a global-FIB (G-FIB).The P-FIB is derived from LSA messages pertaining to P links, the T-FIBis derived from LSA messages pertaining to IPCC links, and the G-FIB isderived from a union of the LSA messages pertaining to P links with theLSA messages pertaining to IPCC links.

In an embodiment of the invention, an interior P node maintains a P-FIBand a G-FIB, while a border P node also maintains a T-FIB in addition tothe P-FIB and the G-FIB. This is because, in an embodiment of theinvention, an interior P node uses the P-FIB to forward IP data packetsand a G-FIB to forward management plane and routing traffic. The borderP node may maintain a T-FIB to route signaling packets (for setting up aforwarding adjacency) over the TDM infrastructure, in an embodiment ofthe invention.

FIG. 8 illustrates how an embodiment of P node 700 classifies andforwards various types of packets. FIG. 8 shows packet header 810, table820, obtained domain information 830, and obtained packet type 840. Insome embodiments of the invention, P node 700 classifies receivedpackets based on information obtained from the IP and TransmissionControl Protocol (TCP) (or User Datagram Protocol) headers of thepacket. Specifically, some embodiments of the invention, determine thetraffic class of a packet based on the domain in which the destinationnode resides and the packet type.

On receiving a packet, P node 700 may determine in which domain thedestination node resides. In some embodiments of the invention, P node700 may determine the IP address of the destination node from the IPheader as illustrated at reference numeral 830. The obtained destinationIP address may then be compared to a mapping of IP addresses-to-domainsto determine in which domain the destination node resides.

The IP address-to-domain mapping may be automatically generated in someembodiments of the invention based on information obtained from LSAmessages. In alternative embodiments, the IP address-to-domain mappingmay be manually configured at each node. Generating the IPaddress-to-domain mapping will be further described below in connectionwith routing protocol enhancements.

In the embodiment of the invention illustrated in FIG. 8, thedestination domain is either a T domain or a P domain. Alternativeembodiments of the invention may include a Wavelength DivisionMultiplexing domain (W domain). Some embodiments of the invention mayhave more than two domains (e.g., a P domain, T domain, and W domain).

In some embodiments of the invention, P node 700 determines the packettype based on information obtained from packet header 810 includinginformation from the protocol field, source port field, and thedestination port field. P node 700 may classify a packet as being oneof: routing, signaling, management, ping, and IP data traffic as shownin FIG. 8. Alternative embodiments of the invention may classify packetsinto different categories and employ more or fewer packet types.

A person of ordinary skill in the art appreciates that according towidely implemented transport layer protocols, particular functions areassociated with particular protocol numbers and particular port numbers.FIG. 8 illustrates that P node 700 may determine a packet's “packettype” based on a transport layer protocol's association betweenfunctions and protocol and port numbers. Table 2 illustrates the packettype classifications made by an embodiment of P node 700 based ontransport layer information obtained from packet header 810.

TABLE 2 Packet Type Processes Implementing Routing Open Shortest PathFirst (OSPF) Signaling Multi-protocol Label Switching ResourceReserVation Protocol - Traffic Engineering (MPLS RSVP-TE) ManagementTelecommunications Network (Telnet) File Transfer Protocol (FTP)Transaction Language 1 (TL1)

Referring again to FIG. 8, table 820 illustrates how P node 700 usesparticular FIBs to forward particular classes of traffic, in anembodiment of the invention. As illustrated in FIG. 8, routing trafficmay be forwarded using the G-FIB because a single instance of a routingprotocol is implemented across the P and T domains. In an embodiment ofthe invention, signaling traffic that is directed at another P node maytraverse only P nodes (with an exception to be discussed next), sinceMPLS tunnels cannot traverse non IP-capable links. Thus, signalingtraffic may use the P-FIB for forwarding. An exception to using theP-FIB to forward signal traffic may be made for signaling traffic thatis exchanged between two border P nodes for the purpose of setting up aforwarding adjacency between the nodes. Such traffic may be explicitlyrouted over T domain nodes, and so should be forwarded using the T-FIBat the first P node. (Note that subsequent nodes, being T nodes, wouldautomatically use the T-FIB for forwarding such traffic, until thepacket emerges at the border P node at the far end.)

All management traffic destined to a T node may be routed using theG-FIB, in an embodiment of the invention, if that link happens to fallon the shortest path. An implicit assumption in the above, of course, isthat there are no malicious users in the network who open a Telnet or anFTP session to an IPCC address with the intent of congesting IPCCbandwidth. That is, all Telnet, FTP, or other management trafficdestined to a T domain address is assumed to be valid, low-bandwidthtraffic, in an embodiment of the invention. For management trafficdestined to a P node, it is preferable that no IPCC links be used(because of the possible limited bandwidth of the IPCC links and theresultant potential for non-T domain related Telnet and FTP applicationsto clog the IPCC links). Thus, for such traffic P node 700 may consultthe P-FIB. The forwarding of IP data traffic (which may have adestination address in the P domain) should not use any IPCC links dueto their possible limited bandwidth, in an embodiment of the invention.To forward such traffic, the node may use the P-FIB, which is derivedfrom information pertaining to P-links.

The ping packets are treated differently from other managementapplications, for the following reason. In a traditional IP network, thecontrol plane and data plane topologies are identical, since each IPlink carries both control and data traffic. Ping can thus be used totroubleshoot both IP control-plane and IP data-plane connectivity in anetwork. In a peer network, however, the presence of IPCC links makesthe topology of the control plane a superset of that of the IP dataplane. Ideally, therefore, we would require two separate versions ofping, one to test IP control channel reachability and the other to testIP data channel reachability. One version of ping that would use the IPtopology to route ping packets, and another version of ping that wouldonly use P links (and not IPCC links). Adding a new ping-like protocolthat would provide dataplane connectivity for just the peer modeloperation is probably impractical. So we propose using ping to test onlycontrol plane reachability. This means that all ping packets must berouted using the G-FIB, in an embodiment of the invention. This impliesthat even if there is no P link between two routers connected with IPCClinks, ping packets will use the IPCC links to successfully travelbetween the nodes.

T Node Architecture and Processes

FIG. 9 is a block diagram illustrating selected elements of T node 900.T node 900 may include: one or more control processors 910, one or moremanagement processors 920, memory 930, one or more Input/Outputinterfaces 940, line cards 950-953, and switch fabric 960. Theillustrated elements may be connected together through systeminterconnect 970. One or more control processors 910 and one or moremanagement processors 920 may include a microprocessor, microcontroller,field programmable gate array (FPGA), application specific integratedcircuit (ASIC), central processing unit (CPU), programmable logic device(PLD), and similar devices that access instructions from system storage(e.g., memory 930), decode them, and execute those instructions byperforming arithmetic and logical operations. In some embodiments of theinvention, one or more control processors 910 and one or more managementprocessors 920 are implemented with a common processor or processors.

Memory 930 may encompass a wide variety of memory devices includingread-only memory (ROM), erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), randomaccess memory (RAM), non-volatile random access memory (NVRAM), cachememory, flash memory, and other memory devices. Memory 930 may alsoinclude one or more hard disks, floppy disks, ZIP disks, compact disks(e.g., CD-ROM), digital versatile/video disks (DVD), magnetic randomaccess memory (MRAM) devices, and other system-readable media that storeinstructions and/or data. Memory 930 may store program modules such asroutines, programs, objects, images, data structures, program data, andother program components that perform particular tasks or implementparticular abstract data types that facilitate system use.

Line cards 950-953 provide an interface between communication channels980-983 and other elements of T node 900. Line cards 950-953 represent abroad range of interface elements capable of providing transmittingand/or receiving ports connecting T node 900 to communication channels980-983. A person of ordinary skill in the art will appreciate that thenumber of line cards in T node 900 may be fewer or greater than thenumber shown in FIG. 9.

Switch fabric 960 provides the interconnect architecture used to switchframes from incoming communication channels (e.g., 980 and 982) withoutgoing communication channels (e.g., 981 and 983). Switch fabric 960represents a wide array of interconnect architectures capable ofswitching TDM frames. Switch fabrics are well known in the art and,therefore, will not be further described except as to embodiments of theinvention.

One or more I/O interfaces 940 may include a hard disk drive interface,a magnetic disk drive interface, an optical drive interface, a parallelport, serial controller or super I/O controller, serial port, universalserial bus (USB) port, a display device interface (e.g., video adapter),a network interface card (NIC), a sound card, modem, and the like.System interconnect 970 permits communication between the variouselements of P node 900. System interconnect 970 may include a widevariety of signal lines including one or more of a memory bus,peripheral bus, local bus, host bus, bridge, optical, electrical,acoustical, and other propagated signal lines.

T node 900 may receive one or more Link State Advertisement (LSA)messages via IPCC 980. The LSA messages may contain information aboutone or more links that are in the same network as T node 900. IPCC 980may be a low bandwidth tunnel in some embodiments of the invention. Inalternate embodiments of the invention, IPCC 980 may be implemented withIP over Data Communication Channel (DCC). In embodiments of theinvention employing a link-state routing protocol, T node 900 maymaintain one or more Link State Databases (LSDBs) containing informationfrom the one or more received LSA messages.

In some embodiments of the invention, T node 900 maintains separateLSDBs for LSA messages pertaining to P links and LSA messages pertainingto IPCC links. In such embodiments, T node 900 may derive separate FIBsfor each LSDB it maintains. In alternative embodiments of the invention,T node 900 maintains a global LSDB and generates separate FIBs byrunning a CSPF algorithm on subsets of the global LSDB.

In either case, T node 900 may generate a G-FIB and a T-FIB, in anembodiment of the invention. The T-FIB may be derived from LSA messagespertaining to IPCC links. The G-FIB may be derived from a union of theLSA messages pertaining to P links with the LSA messages pertaining toIPCC links. In some embodiments of the invention, the G-FIB is derivedby running a CSPF algorithm on the global LSDB.

FIG. 10 illustrates how an embodiment of T node 900 classifies andforwards various types of packets. FIG. 10 shows packet header 1010,table 1020, obtained domain information 1030, and obtained packet type1040. In some embodiments of the invention, T node 900 classifiesreceived packets based on information obtained from the IP and TCP (orUser Datagram Protocol) headers of the packet. Specifically, someembodiments of the invention determine the traffic class of a packetbased on the domain in which the destination node resides and the packettype. T node 900 may determine the packet type and the domain in whichthe destination node resides using analogous techniques to processesdescribed with regards to P node 700 and FIG. 8.

Table 1020 provides an example of how T node 900 may use different FIBsto forward different classes of traffic. Reference numeral 1050illustrates that T node 900 does not forward IP data packets to P nodes,in an embodiment of the invention. Since T node 900 does not typicallyforward IP data packets to P nodes, T node 900 does not need a P-FIB. Ifthe P nodes are implemented according to the discussion associated withFIGS. 8 and 9, IP data traffic should not reach T node 900. Referencenumeral 1060 illustrates that routing traffic may be forwarded using theG-FIB, in an embodiment of the invention.

Similarly, signaling traffic destined to P nodes typically does notreach T node 900, in an embodiment of the invention. An exception,however, is signaling traffic used to establish a forwarding adjacencybetween two P nodes across the T domain (e.g., GMPLS signaling traffic).Since such traffic is normal signaling traffic as far as the T domain isconcerned, it may be forwarded using the T-FIB.

In an embodiment of the invention, signaling traffic destined to a Tnode may be forwarded using the T-FIB, since it is preferable for suchtraffic to travel over IPCC links. In an embodiment of the invention, Tdomain destined signaling traffic should not be forwarded over P linkssince the circuit being established by such signaling will only traverseT links. Thus, in some embodiments of the invention, the correspondingsignaling traffic (e.g., Resource Reservation Protocol messages) alsoshould be restricted to following the same sequence of T nodes throughwhich the data-forwarding path passes.

Reference numeral 1080 illustrates that all management traffic (e.g.,Telnet, FTP, or TL1 commands) whether destined to a P or T node may berouted using the G-FIB. Similarly, reference numeral 1090 illustratesthat Ping traffic in the T domain may follow the same forwarding rulesas other management traffic. In other words, the G-FIB is used forrouting ping packets. Note that any ping traffic originating from a Tdomain of necessity only tests control plane connectivity (there is noway for T nodes to test IP data forwarding plane connectivity) so,unlike the P domain, there is no issue with using the G-FIB to routeping packets.

Routing Protocol Enhancements

In an embodiment of the invention, nodes within a peer type network(e.g., P node 310 and T node 320 shown in FIG. 3) are able to selectbetween forwarding packets over P links or IPCC links. It is desirableto consider link type when routing packets in a peer type networkbecause some traffic classes may only traverse certain types of links.Also, it is desirable to consider link type when routing packets in apeer type network because IPCC links are typically low bandwidth andtherefore data traffic should be routed over P links instead of IPCClinks. Thus, it is desirable to enhance routing protocols used in peertype networks so that the routing protocols enable nodes within anetwork to distinguish between P links and IPCC links (as well as Wlinks). More specifically, in embodiments of the invention usinglink-state routing protocols, it is desirable for receiving nodes to beable to differentiate between OSPF LSA messages describing IPCC linksfrom OSPF LSA messages describing P links.

FIG. 11 is a block diagram illustrating selected portions of LSA message1100. LSA message 1100 comprises a number of fields including OSPFheader 1110, database sequence number 1130, link type 1140, linkidentifier 1150, and advertising router 1160. Routers and switches in apeer type network may send messages like LSA message 1100 to exchangetopology information. Reference numeral 1110 illustrates that LSAmessage 1100 typically includes a header. Header 1110 may specify, interalia, the IP address of the router (or switch) that generated LSAmessage 1100 as well as the version of the link-state routing protocolthat was used.

Bit I shown at reference numeral 1120 may be used to indicate whetherLSA message 1100 is the first in a series of LSA messages. It may benecessary to send a series of LSA messages if, for example, a router isconveying a large topology database. Bit M shown at reference numeral1121 may be used to indicate whether additional LSA messages follow LSAmessage 1100. Field 1130 may be used to number LSA message 1100 so thatthe receiving node can track whether it is receiving an entire sequenceof LSA messages. Fields 1140, 1150, and 1160 may be used to describe onelink in a network and may be repeated for each described link.

Link Type field 1140 may include Link Type bit(s) 1170. Link Type bit(s)1170 may be used to indicate whether the described link is a P link oran IPCC link, in an embodiment of the invention. The node sending LSAmessage 1100 may write either a 1 or a 0 to Link Type bit(s) 1170 toindicate whether the described link is a P link or an IPCC, in anembodiment of the invention. In some embodiments of the invention, LinkType bit(s) 1170 comprises two or more bits. For example, in anembodiment of the invention with three domains (e.g. a P domain, a Tdomain, and a W domain), Link Type bits(s) 1170 may comprise two bits.While Link Type bit(s) 1170 is illustrated as being toward the end ofLink Type field 1150, a person of ordinary skill in the art willappreciate that any bit(s) of Link Type 1140 may be used for Link Typebit(s) 1170. In alternative embodiments of the invention, Link Typebit(s) 1170 may be in a different field of LSA message 1100.

Link Type field 1140 may also include Domain Type bit(s) 1180. DomainType bit(s) 1180 may be used to indicate whether the node sending LSAmessage 1100 resides in a P domain or a T domain (or another domaintype), in an embodiment of the invention. For example, the sending nodemay write either a 1 or a 0 to Domain Type bit(s) 1180 to indicate thatthe sending node resides in either a P domain or a T domain. In someembodiments of the invention, Domain Type bit(s) 1180 comprises two ormore bits. Also, while the illustrated embodiment shows Domain Typebit(s) 1180 as being in the upper portion of Link Type field 1140, aperson of ordinary skill in the art will appreciate that Domain Typebit(s) 1180 may be located in another part of Link Type field 1140. Inalternative embodiments of the invention, Domain Type bit(s) 1180 may belocated in a different field of LSA message 1100.

In an embodiment of the invention, Link Type bit(s) 1170 enable areceiving node to differentiate between OSPF LSA messages describingIPCC links from LSA messages describing P links. Since the receivingnode can differentiate between LSA messages based on the link type ofthe described link, it can keep the two (or more) types of LSA messagesseparate. As described earlier with regards to FIGS. 7-10, a receivingnode may keep different types of LSA messages separate by placing themin logically distinct Link Status Databases (LSDBs) describing the IPtopology, P domain topology, and T domain topology of a network,respectively.

Description of Flow Charts

Turning now to FIGS. 12-17, the particular methods associated withembodiments of the invention are described in terms of computer softwareand hardware with reference to flowcharts. The methods to be performedby elements of a peer type network constitute state machines or computerprograms made up of computer-executable instructions. Describing themethods by reference to a flowchart enables one of ordinary skill in theart to develop such programs including such instructions to carry outthe methods on suitably configured computing devices (e.g., one or moreprocessors of a node) executing the instructions fromcomputer-accessible media. The computer-executable instructions may bewritten in a computer programming language or may be embodied infirmware logic. If written in a programming language conforming to arecognized standard, such instructions can be executed on a variety ofhardware platforms and for interface to a variety of operating systems.In addition, embodiments of the invention are not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the invention as described herein. Furthermore, it iscommon in the art to speak of software, in one form or another (e.g.,program, procedure, process, application, etc.), as taking an action orcausing a result. Such expressions are merely a shorthand way of sayingthat execution of the software by a computing device causes the deviceto perform an action or produce a result.

FIG. 12 is a flow diagram illustrating certain aspects of a method forgenerating a routing advertisement message according to an embodiment ofthe invention. Referring to process block 1210, in one embodiment, anode (e.g., P node 310 and T node 320 shown in FIG. 3) writes a valueindicating a type of link to a field of a routing advertisement message.The value indicating a type of link may be based on one or more types ofswitches connected by the link. For example, in an embodiment of theinvention, a link connecting two IP routers is a type P link. Similarly,a link connecting a TDM switch with one of an IP router and a TDM switchis a type IPCC link, in an embodiment of the invention.

Referring to process block 1220, in one embodiment, a node (e.g., P node310 and T node 320 shown in FIG. 3) writes a value indicating a domaintype to a field of a routing advertisement message. The domain type mayspecify a type of domain in which the sender resides. For example, in anembodiment of the invention, a node may write a value to the routingadvertisement message indicating whether the node resides in a P node ora T node. In some embodiments of the invention, the values indicatinglink type and domain type are written to a Link Type field of a RouterLSA.

FIG. 13 is a flow diagram illustrating certain aspects of a method forprocessing routing advertisement messages according to an embodiment ofthe invention. Referring to process block 1310, in one embodiment, anode (e.g., P node 310 and T node 320 shown in FIG. 3) receives one ormore routing advertisement messages describing one or more links. In anembodiment of the invention, the node may receive one or more LSAmessages over a P link or an IPCC link. The node may obtain a link typefrom each of the one or more received routing advertisement messages atreference numeral 1320. The link type may be based, at least in part, onone or more types of switches connected by the link.

Referring to process block 1330, in one embodiment, the node maintains aseparate routing topology database for each type of link obtained fromthe one or more received routing advertisement messages. In oneembodiment of the invention, the node maintains a first LSDB containinginformation from received LSA messages describing P links and a secondLSDB containing information from received LSA messages describing IPCClinks. As will be further described below with reference to FIGS. 14-17,the node may generate different FIBs based on the different LSDBs.

FIG. 14 is a flow diagram illustrating certain aspects of a method 1400for processing Link State Advertisement messages in an IP router,according to an embodiment of the invention. Referring to process block1410, in one embodiment, an IP router receives an LSA message describinga link between two nodes in a network. The IP router determines a linktype for the link at process block 1420. In an embodiment of theinvention, the link type is based on one or more types of switchesconnected by the link.

The IP router may determine from the received LSA message a domain typefrom which the LSA message was sent at process block 1430. Similarly,the IP router may determine an IP address of the node that sent the LSAmessage at process block 1440. Referring to reference numeral 1450, insome embodiments of the invention, the IP router may update a mapping ofIP addresses to domain type based on the information determined inprocess blocks 1430 and 1440. In alternative embodiments of theinvention, a mapping of IP address to domain type may be manuallyconfigured for the IP router.

In process block 1460, the IP router may update a first LSDB for type Plinks based on the received LSA message, if the LSA message describes atype P link. Similarly, the IP router may update a second LSDB for typeIPCC links, if the LSA message describes a type IPCC link. Thus, in anembodiment of the invention, the IP router maintains at least twologically distinct LSDBs: a P link LSDB and an IPCC link LSDB.

Referring to process block 1480, in an embodiment of the invention, theIP router generates a P link-Forwarding Information Base (P-FIB) basedon the P link LSDB. The IP router may use the P-FIB to forward packetsover P links. In one embodiment of the invention, the P-FIB is generatedby running a Constrained Shortest Path First (CSPF) algorithm on the Plink LSDB.

The IP router may generate an IPCC link-FIB (T-FIB) based on the IPCClink LSDB as illustrated at reference numeral 1490. The IP router mayuse the T-FIB to forward packets over IPCC links. In one embodiment ofthe invention, the T-FIB is generated by running a CSPF algorithm on theIPCC link LSDB.

Referring to process block 1495, in an embodiment of the invention, theIP router generates a global-FIB (G-FIB) based on the union of the Plink LSDB with the IPCC link LSDB. The G-FIB may be used to forwardpackets over either P links or IPCC links. In one embodiment of theinvention, the G-FIB is generated by running a CSPF algorithm on theunion of the P links LSDB with IPCC link LSDB.

FIG. 15 is a flow diagram illustrating certain aspects of a method forprocessing a packet in an IP router, according to an embodiment of theinvention. The IP router receives a packet at process block 1510.Referring to process block 1520 the IP router determines a domain typefor a domain in which a destination node of the received packet resides.In one embodiment of the invention, the IP router determines the domaintype for the destination node by obtaining the destination IP addressfrom the received packet and comparing it to a mapping of IP addressesto domain types. As previously discussed the mapping of IP addresses todomain types may be automatically generated from information obtainedfrom LSA messages or manually configured at each node.

Referring to process block 1530, in an embodiment of the invention, theIP router determines a packet type for the received packet. The IProuter may determine the packet type based, at least in part, oninformation obtained from various packet headers. For example, in oneembodiment of the invention, the IP router determines transport layerprotocol type and port information from various packet headers of thereceived packet. In one embodiment of the invention, the IP routerdetermines the packet type of the received packet to be one of: routing,signaling, management, ping, and IP data traffic.

The IP router determines which FIB to use when forwarding the receivedpacket at reference numeral 1540. In an embodiment of the invention, theIP router may select an FIB based on the determined packet type anddestination domain of the packet. For example, the IP router may selectthe P-FIB to forward an IP data packet, in an embodiment of theinvention.

FIG. 16 is a flow diagram illustrating certain aspects of a method forprocessing Link State Advertisement (LSA) messages in a TDM switch,according to an embodiment of the invention. Referring to process block1610, in an embodiment of the invention, a Time Division Multiplexing(TDM) switch receives an LSA message describing a link between two nodesin a network. The TDM switch determines a link type for the link atprocess block 1630. In an embodiment of the invention, the link type isbased on one or more types of switches connected by the link. Processblocks 1630, 1640, and 1650 are similar to process blocks 1430, 1440,and 1450 and, therefore, will not be further described.

In process block 1660, the TDM switch may update a first LSDB for typelinks based on the received LSA message, if the LSA message describes atype link. Similarly, the TDM switch may update a second LSDB for typeIPCC links, if the LSA message describes a type IPCC link. Thus, in anembodiment of the invention, the TDM switch may maintain two or morelogically distinct LSDBs. While process 1600 is directed to maintaininga P link LSDB and an IPCC link LSDB, a person of ordinary skill in theart will appreciate that alternative embodiments may maintain adifferent selection of LSDBs (e.g., a global LSDB and an IPCC LSDB).

Referring to process block 1680, in an embodiment of the invention, theTDM switch generates an IPCC link—Forwarding Information Base (T-FIB)based on the IPCC link LSDB. The TDM switch may use the T-FIB to forwardpackets over IPCC links, in an embodiment of the invention. In oneembodiment, the T-FIB is generated by running a CSPF algorithm on theIPCC link LSDB.

The TDM switch may generate a global—FIB (G-FIB) as illustrated atreference numeral 1690. In an embodiment of the invention, the G-FIB isgenerated by running a CSPF algorithm on the union of the P link LSDBwith the IPCC link LSDB. The G-FIB may be used to forward packets overeither P links or IPCC links, in an embodiment of the invention.

FIG. 17 is a flow diagram illustrating certain aspects of a method forprocessing a packet in a TDM switch, according to an embodiment of theinvention. The TDM switch receives a packet at process block 1710.Referring to process block 1720, the TDM switch determines a domain typefor a domain in which a destination node of the received packet resides.In one embodiment of the invention, the TDM switch determines the domaintype for the destination node by obtaining the destination IP addressfrom the received packet and comparing it to a mapping of IP addressesto domain types. As previously discussed, the mapping of IP addresses todomain types may be automatically generated from information obtainedfrom LSA messages or manually configured at each node.

Referring to process block 1730, in an embodiment of the invention, theTDM switch determines a packet type for the received packet. The TDMswitch may determine the packet type based, at least in part, oninformation obtained from various packet headers. For example, in oneembodiment of the invention, the IP router determines transport layerprotocol type and port information from various packet headers of thereceived packet. In one embodiment of the invention, the TDM switchdetermines the packet type of the received packet to be one of: routing,signaling, management, ping, and IP data traffic.

The TDM switch determines which FIB to use when forwarding the receivedpacket at reference numeral 1740. In an embodiment of the invention, theTDM switch may select an FIB based on the determined packet type anddestination domain of the packet. For example, the TDM switch may selectthe G-FIB to forward s signaling packet, in an embodiment of theinvention.

It should be appreciated that reference throughout this specification to“one embodiment” or “an embodiment” means that a particular feature,structure or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention.Therefore, it is emphasized and should be appreciated that two or morereferences to “an embodiment” or “one embodiment” or “an alternativeembodiment” in various portions of this specification are notnecessarily all referring to the same embodiment. Furthermore, theparticular features, structures or characteristics may be combined assuitable in one or more embodiments of the invention.

Similarly, it should be appreciated that in the foregoing description ofexemplary embodiments of the invention, various features of theinvention are sometimes grouped together in a single embodiment, figure,or description thereof for the purpose of streamlining the disclosureaiding in the understanding of one or more of the various inventiveaspects. This method of disclosure, however, is not to be interpreted asreflecting an intention that the claimed invention requires morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive aspects lie in less than allfeatures of a single foregoing disclosed embodiment. Thus, the claimsfollowing the detailed description are hereby expressly incorporatedinto this detailed description, with each claim standing on its own as aseparate embodiment of this invention.

1. A method for operating an Internet Protocol (IP) router in a peermodel network comprising: receiving, at the IP router, a Link StateAdvertisement (LSA) message describing a link between two nodes in thenetwork; and determining from the received LSA message a link type forthe link, the link type based on one or more types of switches connectedby the link.
 2. A method for routing an incoming IP packet at an IProuter in a peer model network comprising: receiving a packet at the IProuter; determining a domain type for a domain in which a destinationaddress of the received packet resides; and determining a packet type ofthe received packet.
 3. An Internet Protocol (IP) router comprising: afirst Link State Database (LSDB) to provide information about one ormore type P links; and a second LSDB to provide information about one ormore type IPCC links.